%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Iteration 3
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Iteration 3: Transaction Database (Av3)}
                
In the third iteration we decompose the \emph{Transaction Database} because of its high importance to the SAB service. For this decomposition we consider QaS Av3: "Transaction database failure". The use case relevant to this is:
\begin{itemize}
	\item UC6: Consult transaction history of account
\end{itemize}
        
The drivers can be summarized in the following requirements:
\begin{itemize}
  \item Transactions can't be lost during processing if the system fails.
  \item Transactions can still be ordered when the transaction database has failed. It should be possible to store at least 3 hours of data after the failure.
  \item The system should be able to autonomously detect failure of the transaction database. This detection should be done within 5 minutes. 
  \item An operator should be notified of the failure.
  \item The database should be at least 99.99\% up and running, which corresponds to 52 min. and 34 sec. a year.
\end{itemize}


To satisfy this driver we considered different availability tactics to find an appropriate solution.
\begin{description}
    \item[Fault Detection:] \hfill \\
        \vspace{-5mm} 
        \begin{description}
            \item[Ping/echo or Heartbeat:]
            The System should be able to autonomously detect failure of the transaction database, so a ping/echo or heartbeat system will be needed that can detect failure of the database within 5 minutes.
            
            \item[Exceptions:]
            Exceptions can also be use so that database failure can be detected as soon as it is queried.
            
        \end{description}
        
        
    \item[Fault Recovery:] \hfill \\
        \vspace{-5mm} 
        \begin{description}
            \item[Active redundancy (hot restart):]
            Active redundancy can be used as a solution to this driver, but it is a costly solution because the whole transaction database and communications need to run in parallel. Slowdown is also possible because the databases have to wait for each other to finish before accepting a succinct write.
            
            \item[Passive redundancy (warm restart):]
            Passive redundancy can also be used as a solution to this driver. Recover time will be a bit longer than with active redundancy, but the solution is a bit cheaper because the communications channel does not need to be duplicated. The slowdown associated with active redundancy can be avoided because the backup can queue writes.
            
            \item[Spare:]
            A spare is also an option. The operator will be able to restart the spare and let it be set to the appropriate state. Making checkpoints and logging all state changes needs to be done to be able to restore the spare to the correct state. A spare will take longer (order of minutes) to get up and running than passive or active redundancy, but will be cheaper because it does not need to run the whole time.
            
            \item[Shadow Operation:]
            This might be an option to restore the original database if a spare or active/passive redundancy is used.
            
            \item[State resynchronization:]
            This might be an option to restore the original database if active/passive redundancy is used. State resynchronization can also be used to synchronize the log files with the database once it is again up and running.
            
            \item[Checkpoint/rollback:]
            A checkpoint/rollback can be used to restore the system to a consistent state when passive redundancy or a spare is used.
            
        \end{description}
        
        
    \item[Fault prevention:]  \hfill \\
            \vspace{-5mm} 
            \begin{description}
            \item[Transactions:]
            Transaction handlers work concurrently on the database. To avoid problems caused by race conditions, a transactional database is used.
            
            \item[Process monitor:]
            A process monitor can be used to automatically initialise the active or passive redundant database.
            \end{description}     

\end{description}
     
        
        
% Insert figure
\begin{figure}[!ht]
    \centering
        \includegraphics[width=1.0\textwidth]{images/It3_Av3_componentdiag.png}
    \caption{Component diagram after iteration 3.}
    \label{fig:It3_Av3_componentdiag}
\end{figure}
        
        
The result of this decomposition of the \emph{Transaction Database} can be seen in figure \ref{fig:It3_Av3_componentdiag}. To deal with this architectural driver we will add a \emph{Transaction Database Monitor} that monitors the \emph{Transaction Storage} with a ping/echo system each 5 minutes. The monitor will also be notified of possible exceptions thrown by the \emph{Transaction Storage} so that the fault recovery can be done as soon as possible.

The \emph{Transaction Storage} will hold all processed transaction commands. It is implemented as a transactional database to allow multiple transaction commands on different accounts to be processed at the same time.

Note that from this iteration on, the \emph{transactionAccess} interface is split up in a \emph{logTransaction} and a \emph{readTransaction} interface. This is because logging requires special functionality.

If a fault is detected the \emph{Transaction Database Monitor} will notify the \emph{Operator} and start the recovery process. This allows the system to warn the customer when they try to access their transaction history and to delay any operations which require the database to be checked (i.e. checking the response deadline of SWIFT responses and initiating fraud detection).

The recovery process will let a passive redundant database, the \emph{Transaction Storage Spare}, take over by first checking the state consistency with the logs and then take over as the new \emph{Transaction Storage}. The operator will fix the old database and restart this system. When the old system is repaired and restarted it will update its state and act as a passive redundant database to the now operational \emph{Transaction Storage}.

In order that transaction commands can continue to be processed a log file, the \emph{Transaction Log}, will be placed parallel to the database. This log file will work constantly and maintains all database changes of the last 3 hours. This log file will be used to resynchronize the state of the passive redundant spare each hour or in case of failure.
        

Requirements can be divided over relevant components as follows:
\begin{itemize}
 
    \item \emph{Transaction Database Monitor}
    \begin{itemize}
     \item Av3: Transaction database failure should be detected autonomously.
    \end{itemize}
    
    
    \item \emph{Transaction Storage}
    \begin{itemize}
     \item UC6: Consult transaction history of account
    \end{itemize}
    
    
    \item \emph{Transaction Log}
    \begin{itemize}
     \item Av3: Incoming data is stored elsewhere.
    \end{itemize}
    
    
    \item \emph{Transaction Storage Spare}
    \begin{itemize}
     \item Av3: No transaction data is lost when the database fails.
    \end{itemize}

    
\end{itemize}  







